In a peer-to-peer environment, two peer devices may exchange events end-to-end without relying on a central server. In this environment, the peer devices must have a process for unambiguously ordering these events (meaning that the event order should be the same on both peer devices). This process is complicated when little to no quality guarantees can be assumed about the communication channel between the two peers. For example, in some systems, the exchanged events may be lost, delayed, or arrive out of order.
Hence, in the peer-to-peer environment, there is no central server for the peer devices to rely on for ensuring correct event ordering. This peer-to-peer environment (as opposed to a communications environment relying on the central server) is generally preferred for security and scalability reasons. However, the peer-to-peer communication channel is unreliable including where events may be lost, delayed, or arrive out of order. In the presence of unreliable communication channel between two peer devices, it cannot be assumed that both peer devices have the same set of known (sent or received) events. To address this issue, event ordering solutions have been developed to attempt to ensure that both peer devices could order the events in the same way. However, these existing event ordering solutions have exhibited various limitations.
For example, one approach is to use absolute timestamps. Unfortunately, this approach is unreliable because the time configured on the two peer devices may differ, and so the event ordering by the two peer devices cannot be assumed to be the same.
Another approach is to use a counter for event identifiers (IDs), which traditionally has involved the use of Lamport timestamps. Lamport timestamps generally work well, but this approach produces the same timestamps for “concurrent” events which require further disambiguation based on an external deterministic method such as comparing process IDs. However, in reality, access to such disambiguation method may be limited. For example, relying on process IDs is not possible when the peer devices are running on different types of machines. Another problem with disambiguation is that it may be biased, e.g., if one peer device continuously “wins” the disambiguation process, the event ordering of “concurrent” events will be always the same, making the order biased.
There is thus a need for addressing these and/or other issues associated with the prior art.